-
Notifications
You must be signed in to change notification settings - Fork 306
KaTeX (2/n): Support horizontal and vertical offsets for spans #1452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
d00e10f
to
7ff4f9e
Compare
7ff4f9e
to
c0dd0a1
Compare
sealed class KatexNode extends ContentNode { | ||
const KatexNode({super.debugHtmlNode}); | ||
} | ||
|
||
class KatexSpanNode extends KatexNode { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One point that I noticed while developing #1478 (and checking how my draft of that branch interacted with this PR): it'd be good for this commit:
e268041 content: Handle vertical offset spans in KaTeX content
to get split up like so:
- First, an NFC prep commit introduces the distinction between KatexNode and KatexSpanNode. At this stage, the latter is the only subclass of the former.
- Then another commit makes the substantive changes this commit is about, including introducing the sibling subclasses KatexVlistNode and KatexVlistRowNode.
One reason that'd be useful is that the split between KatexNode and KatexSpanNode is somewhat nontrivial in itself: some of the references to KatexNode continue to say KatexNode, while others switch to saying KatexSpanNode, so the commit is expressing meaningful information by its choices of which references go which way.
b17033a
to
16cb28f
Compare
This applies the correct font scaling if the KaTeX content is inside a header.
And rename previous type to KatexSpanNode, also while making it a subtype of KatexNode.
Implement handling most common types of `vlist` spans.
Negative margin spans on web render to the offset being applied to the specific span and all the adjacent spans, so mimic the same behaviour here.
16cb28f
to
376cfe7
Compare
It seems like this had slipped through the cracks :-) but it looks ready for review, so I applied the label. Also rebased now that #1478 is merged, so this now contains only the changes that are specific to this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! I think the last few commits will need some tests for the more complicated parts. I went over the changes and left some comments, but haven't extensively tested the changes manually yet.
_logError('KaTeX: Unsupported CSS property: $property of ' | ||
'type ${expression.runtimeType}'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One other possibility for this to be logged is when _getEm
returns null. I think for debugging purpose, including the value expression
might be helpful.
if (expression is css_visitor.EmTerm && expression.value is num) { | ||
return (expression.value as num).toDouble(); | ||
} | ||
return null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's perhaps have a short dartdoc on what this does and what null
means, since the if (…Em != null) continue;
's make this return value quite relevant.
final double? heightEm; | ||
final double? marginRightEm; | ||
final double? topEm; | ||
final double? verticalAlignEm; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a good idea to separate them into groups; to add on this, how about having a short comment before each group explaining how we group them together (like we do with design variables)?
} | ||
|
||
return Container( | ||
margin: styles.marginRightEm != null && !styles.marginRightEm!.isNegative |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, !styles.marginRightEm!.isNegative
seems a bit contrived. I think isNegative
negated is not as clear as >= 0
. However, do we need the margin when marginRightEm
is 0?
styles: inlineStyles != null | ||
? styles.merge(inlineStyles) | ||
: styles, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having tests for this (the case when there are both inline styles and others) might be useful. Not sure how common that is.
child: RichText(text: TextSpan( | ||
children: List.unmodifiable(row.nodes.map((e) { | ||
return WidgetSpan( | ||
alignment: PlaceholderAlignment.baseline, | ||
baseline: TextBaseline.alphabetic, | ||
child: switch (e) { | ||
KatexSpanNode() => _KatexSpan(e), | ||
KatexVlistNode() => _KatexVlist(e), | ||
KatexNegativeMarginNode() => _KatexNegativeMargin(e), | ||
}); | ||
}))))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like this can be replaced with _KatexNodeList(nodes: row.nodes)
child: Text.rich(TextSpan( | ||
children: List.unmodifiable(node.nodes.map((e) { | ||
return WidgetSpan( | ||
alignment: PlaceholderAlignment.baseline, | ||
baseline: TextBaseline.alphabetic, | ||
child: switch (e) { | ||
KatexSpanNode() => _KatexSpan(e), | ||
KatexVlistNode() => _KatexVlist(e), | ||
KatexNegativeMarginNode() => _KatexNegativeMargin(e), | ||
}); | ||
}))))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_KatexNodeList
also seems helpful here.
} | ||
|
||
class _KatexNegativeMargin extends StatelessWidget { | ||
const _KatexNegativeMargin(this.node); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because the name implies that the margin should be negative, maybe we should also add assertions to ensure that that is true.
List<KatexNode> _parseChildSpans(dom.Element element) { | ||
return List.unmodifiable(element.nodes.map((node) { | ||
if (node case dom.Element(localName: 'span')) { | ||
return _parseSpan(node); | ||
} else { | ||
var resultSpans = <KatexNode>[]; | ||
for (final node in element.nodes.reversed) { | ||
if (node is! dom.Element || node.localName != 'span') { | ||
throw KatexHtmlParseError(); | ||
} | ||
})); | ||
|
||
final span = _parseSpan(node); | ||
resultSpans.add(span); | ||
|
||
if (span is KatexSpanNode) { | ||
final marginRightEm = span.styles.marginRightEm; | ||
if (marginRightEm != null && marginRightEm.isNegative) { | ||
final previousSpansReversed = | ||
resultSpans.reversed.toList(growable: false); | ||
resultSpans = []; | ||
resultSpans.add(KatexNegativeMarginNode( | ||
marginRightEm: marginRightEm, | ||
nodes: previousSpansReversed)); | ||
} | ||
} | ||
} | ||
|
||
return resultSpans.reversed.toList(growable: false); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neat solution! A bit tricky to understand. I think we can use QueueList
(and with .addFirst
) to avoid the hassle of reversing and unreversing the list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will be helpful to have tests for this.
final pstrutStyles = _parseSpanInlineStyles(pstrutSpan)!; | ||
final pstrutHeight = pstrutStyles.heightEm ?? 0; | ||
|
||
// TODO handle negative right-margin inline style on row nodes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we consider this complete after the final commit ("content: Support negative right-margin on KaTeX spans")? I'm not too sure if something else is left to be done here.
This seems to contradict with the earlier assumption that vlist elements contain only the height
style.
Stacked on top of: #1408
Related: #46